In the proprietary business support systems (BSS) and operation support systems (OSS) of a telecommunications network, many systems are needed to communicate together to successfully run and maintain a service provider network. Each such system needs to exchange information, which can be achieved by the engineering of a mediation node that extracts the information from the system's database or business logic.
Alternatively, a network element management system (EMS) may be provided in the network to expose network information to other systems via machine interfaces. A typical such EMS exposes network configuration information in document style via a bulk Configuration Management Integration Reference Point (CM IRP) or so-called north-bound interface of the EMS. This document may be in the Common Object Request Broker Architecture (CORBA) language or Extensible Markup Language (XML).
A typical deployment would see a remote third-party network planning application connect to the EMS via the north-bound interface thereof to download network configuration information in the above-mentioned document style. This information is then loaded into the business logic of the remote network planning application, whereupon some of the data can be changed and uploaded in the same document style back to the EMS, which then uploads the changed configuration information to network elements or nodes located within the network.
The information contained in the document exchanged through the north-bound interface comprises a sequence of connected data structures, which are referred to as Managed Objects (MO) in network management system (NMS) terminology. Each MO has a predefined set of attributes or parameters that can be set and can take the form of numerical or textual data types.
In summary, a third-party system (or it can be a third-party application running on the third-party system) will read network information in the form of MOs, apply some algorithms to the information and upload the changes to the MO attributes via the north-bound interface. The EMS of the network will then process the network changes and reconfigure the network elements that are affected by the MO changes.
The above-mentioned procedure for a typical EMS of a telecommunications network will now be described with reference to FIG. 1 of the accompanying drawings. A third-party application 10 retrieves network information as an XML document 12 via the north-bound interface 13 of the EMS 11 of the telecommunications network. The third-party application 10 then applies some business logic to this information, such as to read, write, delete or add MOs. The amended document 12 is then uploaded via the north-bound interface 13 to the EMS 11. The EMS 11 then communicates with appropriate network elements 14 of the telecommunications network to implement the changes in the network.
In some types of EMS 11, the MO information is also cached in a cache store 15 provided within the EMS 11. This cached information is configured as either ACTIVE (what is actual in the network elements 14) or PLANNED (what the configuration will be after the changes are implemented). The information within the cache store 15 is then synchronised on a regular basis with appropriate network elements 14 of the telecommunications network. This synchronisation is facilitated by the logic stored at a network element adaptor (NEAD) 16 contained within the EMS 11. It should be noted that the cache is created and maintained using different replication strategies: this allows for different level synchronisation intervals of the MOs, since some MOs change a lot some are fairly static.
The key assumption is that network changes are exchanged through the EMS 11 via the north-bound interface 13. The bulk style of the interface 13 takes a snap shot of the network to be exported to the third party application 10. In this environment, it is important that the EMS 11 is able to quickly service requests from the third party application 10 and therefore it is important that the some information is cached to support the bulk interface style.
The problems with known arrangements can be summarised into three key areas. Firstly, an inherent problem with any cache system is to decide what should be cached and to decide upon how often the information kept in the cache 15 should be synchronised. The current approach is to setup the caching policies based on expected usage, this being based on how the network application makes use of it. However, since third-party applications also make use of the information, a policy based on network application usage does not present a true picture of how and when the information is updated. As such, the actual usage might differ and the caching policies would have to reflect this.
Secondly, north-bound or other bulk style interfaces 13 to the EMS 11 are not cognisant of the data in their payload. As a result no optimisation is used on information being received or sent from EMS 11.
Thirdly, the final and most important problem is in relation to the verification of the configuration information being sent to the EMS 11 from the third-party application 10. The graphical user interface (GUI) 17 of the EMS 11 application encodes business logic, which controls the options available to third-party application network engineers. The north-bound or other bulk style interfaces 13 by their nature push this responsibility to the third-party application 10 that creates the bulk imports. Although a business logic element 18 of the EMS 11 checks for some syntax related information on information that is uploaded on the bulk import, the information is not verified. Hence, there is a risk that the uploaded information may contain errors or omissions, which may adversely affect the operation of the network elements 14.
We have now devised an improved method and apparatus for the management of network configuration in telecommunications networks.